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Abstract 



Module mechanisms have received considerable theoretical attention, but 
the associated concepts of separate compilation and linking have not been 
emphasized. Anomalous module systems have emerged in functional and 
object-oriented programming where software components are not separately 
typecheckable and compilable. In this paper we provide a context where link- 
ing can be studied, and separate compilability can be formally stated and 
checked. We propose a framework where each module is separately compiled 
to a self-contained entity called a linkset; we show that separately compiled, 
compatible modules can be safely linked together. 
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1 Introduction 



Program modularization arose from the necessity of splitting large programs into frag- 
ments in order to compile them. As system libraries grew in size, it became essential to 
compile the libraries separately from the user programs; libraries acquired interfaces 
that minimized compilation dependencies. A linker was used to patch compiled frag- 
ments together. 

It was soon realized that modularization had great advantages in terms of large- 
grain program structuring [19]. Much fundamental and practical research focused on 
modularization principles and properties; milestones in this process are embodied in 
such constructs as object-oriented classes, Modula-2 modules, and Standard ML func- 
tors. 

Since program structuring is of great importance in software engineering, there is 
motivation for continuously increasing the flexibility and convenience of modulariza- 
tion constructs. Unfortunately, in the shadow of many exciting developments there has 
been a tendency to overlook the original purpose of modularization. Some language 
definitions specify what are to be the compilation units (e.g.: Ada [12]), but others do 
not (e.g.: Standard ML [17]). A paradoxical question then arises: when does a module 
system really support modularization (meant as separate compilation)? 

In designing and formalizing module systems, many proposals have focused on 
the analogy between modules and data structures, and between interfaces and data 
types, e.g. as in Burstall's influential paper [4]. In such proposals, modules and inter- 
faces become language constructs to program with. This approach has the advantage 
of adding clean programmability to the area of system configuration, where it has tra- 
ditionally been lacking. When pushing this approach to extremes, though, there is the 
danger of losing sight of the requirements of separate compilation. 

In this paper we take a different approach in order to maintain a natural and accu- 
rate view of the separate compilation and linking process. We consider linking as the 
fundamental process from which module mechanisms arise: not merely as a technique 
for managing large programs and libraries. Further, we consider modularization as in- 
separable from separate compilation: not merely as a program structuring mechanism. 
Instead of considering interfaces as just another program construct, we look at interfac- 
es as typing environments that are intrinsically external to the programming language. 
By adopting this view we can develop modularization mechanisms with precise no- 
tions of separate compilation, inter-module typechecking, and linking. 

Today, the purpose of separate compilation is to be able to write, check, deliver, 
maintain, and upgrade libraries of code, possibly hiding the source code from the cli- 
ents of the libraries. Many things can go wrong in languages and environments de- 
signed (or coerced) to support separate compilation. To understand the range of 
problems that may arise, let us consider an example of a software development cycle 
and the obstacles that may impede it. In this example, a library module and a user mod- 
ule interact over time; it is instructive to assume that library development and client 
development happen in separate locations. 
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Day 1: Library description. A library interface l U b is publicized before any correspond- 
ing implementation module Mub is made available. The purpose is to allow early de- 
velopment of client software that will later be integrated with the library. Therefore, in 
this scenario we assume that there exists a notion of largely code-free interfaces. 

Obstacles 

• Early programming languages, both procedural and object-oriented, did not sepa- 
rate interfaces from implementations. 

• Languages that are designed to be "small" or untyped often lack interfaces. 

• Certain language features may require global analysis and may thus conflict with 
modularity; examples are multimethods [7] and overloading. 

Day 2: User program description. A user interface Iu S r is written without yet producing 
the corresponding user module Mu sr . The purpose is to begin designing the structure 
of Musr and its interaction with lub before making any actual implementation commit- 
ments. The interface Iu sr is based on lub- 
Obstacles 

• It is important to be able to write Iu sr on the basis of definitions contained in lub) the 
purpose of lub is often to define shared types. Modula-2, for example, allows type def- 
initions in interfaces. However, this feature has surprisingly complex interactions with 
the type theory of modules, and even advanced module systems like Standard ML's 
did not consider it until recently [11, 13]. 

Day 3: User program compilation. A user module Mu sr is written and compiled. It is 
checked to be compatible with Iu sr and lub- The compilation of Mu sr produces a linkable 
image L Usr . No running program is generated yet because no implementation of lub has 
been delivered. 

Obstacles 

• The code of generic library modules may have to be instantiated before the user code 
can be typechecked; then an implementation Mub of hib must be available to typecheck 

M Usr . 

• The instantiation of generic interfaces and modules performed by the client may pro- 
duce unexpected type errors in the library code that were not detected by simple test- 
ing of the library [18, page 47]. 

• Some object-oriented languages need to retypecheck superclass code (potentially li- 
brary code) to verify the correct use of Self-types in subclasses [20] . 

• Standard ML's transparent signatures [15] allow situations where Mu sr depends on 
the types defined in a particular implementation of lub) therefore Mu sr cannot be isolat- 
ed by lub from that implementation [13]. 

• Even when it is possible to typecheck Mu sr purely against lub, it may be that lub does 
not convey all the information necessary to produce a linkable image Lu sr - For example: 
the compiler may insist on performing global flow analysis, or some routines of lub 
may require inlining, or the layout of opaque types in l U b may have to be determined. 
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Day 4: Library compilation. A library module Mub is produced that matches the inter- 
face hib- It is compiled to a linkable image hub- The pair (Jub, Lab) is stored in a public 
repository. 

Obstacles 

• It may be the case that a library cannot be compiled even though its full code is avail- 
able. This happens for generic module mechanism in the style on templates (as in C++, 
ADA, and Modula-3) where generic library modules must be instantiated by client (or 
test) modules before typechecking can take place. 

Day 5: User program linking. The user fetches the archived library Lut associated with 
Iub from the repository. A user program P Usr is produced by linking hub with Ljj sr . 
Obstacles 

• Even though Mub matches Iub, Mu sr matches Iu sr , and Iu sr matches Iub, it may be the 
case that P Usr produces run-time type errors. In Eiffel, for example, separate typecheck- 
ing of classes does not imply that the whole program is type-safe [8, 16]. 

• Some mechanisms (Modula-3's revelations [18], Standard ML's smartest recompila- 
tion [21], Eiffel's proposed link-time safety analysis) delay some type checks until link 
time: the user may discover at that point internal inconsistencies in the libraries. 

• The linked program should have the same effect as a program obtained by merging 
all the sources together and compiling the result in a single step. Such a merging of 
sources is not often characterized; then the semantics of linking is undetermined. 

Day 6: Library implementation evolution. A new library module M'ls that matches Iub 
is produced. A new pair {Iub, L'ub) is stored in the public repository. 

Obstacles 

• Changes to the implementation of a library superclass may alter object layout; this 
may require recompilation of user subclasses, even when the public interface of the su- 
perclass does not change. 

• When many interdependent libraries are archived, there may be transients when the 
library implementations in the repository are mutually inconsistent, and when the 
linking of user programs should fail. 

Day 7: User program relinking. The user program P Usr is now out of date, but Iub has 
not changed. Therefore, a new user program P'usr can be regenerated without recom- 
pilation by linking L'm, with Lu sr - 
Obstacles 

• Will the result of running the relinked program be the same as if it had been recom- 
piled first? It is natural to expect so. However, David Griswold [10] has pointed out 
that this property fails for Java (without compromising type safety), because overload- 
ing is treated differently during compilation and linking. 
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Day 8: Library interface evolution. A revised interface I'm, and a corresponding library 
module M"ls are generated. A new pair (I~ub, L'm) is stored in the public repository, 
replacing (I Lib , L' Lib ). 
Obstacles 

• When many such interdependent libraries are archived, there may be transients 
when the library interfaces in the repository are mutually inconsistent and when the 
compilation of user code should fail. 

Day 9: User program adaptation. Because of the new M~ub, the user program is now 
out of date. Moreover, Musr and Iu sr do not match I'm,. Thus, Iu sr is changed to a com- 
patible r U sr, and a new M~u S r is compiled to L~ Usr - Finally, a new P'usr is produced by 
linking L~ Lib with L~ Usr . 
Obstacles 

• Unless code dependencies are tracked properly [1], the new version of the user code, 
L'usr, may be accidentally linked with the old library, hub, (or vice versa) causing arbi- 
trary execution errors even in safe languages. 

As discussed in this scenario, the potential and actual problems in separate com- 
pilation and linking are many and varied. Moreover, the example sketched above con- 
cerns mostly traditional environments. Linkers are now getting smarter, taking 
advantage of type information at link time and performing dynamic linking at run 
time. As an emerging issue, security in Java depends not only on safe typing, but also 
on safe linking [9]. Thus the potential for problems is increasing. 

We do not propose to attack all the obstacles at once: some have to do with lan- 
guage design, some with implementation technology, and some with environment en- 
gineering. However, it should be clear that separate compilation and linking have 
become complex enough that they require very careful thinking, and possibly formal 
thinking. At every point in the software development process we would like to be con- 
fident that our programs are correctly linked. This work is meant as a formal step in 
this direction, mostly concerning the interactions of linking with type safety. 

In this paper we make a number of simplifying assumptions in the attempt to ren- 
der the technical development as rigorous and simple as possible. Our main intent is 
to provide a road map for more ambitious efforts concerning realistic module systems. 
For concreteness and simplicity, we apply our ideas to a simple module system for a 
first-order language (Fx) and we hint at possible extensions. 

Section 2 introduces basic terminology about separate compilation and proposes a 
formal interpretation of linking. Sections 3 and 4 review the simply typed X-calculus 
and introduce a simple module system for it. Sections 5 and 6 study linksets and link- 
ing algorithms. Section 7 maps modules to linksets and section 8 establishes a reason- 
ing system for the soundness of separate compilation and linking. Finally, section 9 
draws some conclusions and discusses future work and extensions. 
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2 Linking 

In programming environments, linking is the process that turns a collection of program 
fragments into a runnable program. In this section we discuss the formalization of link- 
ing in terms of the manipulation of judgments. 

2.1 Program Fragments 

A program fragment is, in first approximation, any syntactically well-formed program 
term, possibly containing free variables. Separate compilation is intended as the separate 
typechecking and separate code generation of program fragments. We avoid issues of 
code generation by always working at the source-language level, even when discuss- 
ing linking. Therefore, compilation is simplified to typechecking. (We believe this is 
not an important restriction for our purposes: the hardest part of separate compilation 
is separate typechecking, at least from the point of view of language design.) 

A program fragment cannot be compiled (or typechecked) in isolation, but it can 
be compiled in the context of adequate information about missing fragments. This in- 
formation is usually given in terms of an environment for the free variables of a frag- 
ment. The notion of a typing environment E for a program fragment a is routinely 
employed in the formalization of typability; a judgment £ h a:A establishes a type A for 
the program fragment a with respect to the environment E. 

The separate compilation of a fragment a can be seen as the compilation of a judg- 
ment E h a:A, because the judgment contains sufficient (although incomplete) informa- 
tion about related fragments. During the compilation of this judgment, the types of the 
free variables of a are found in E (without any associated values). Since the values of 
free variables are missing, the compilation is incomplete, but can still be carried out sep- 
arately, i.e., modulo the missing values. 

A complete program is a closed term; that is, a term with no free variables. A com- 
plete program is self-contained: it can be typed in an empty environment, and its com- 
pilation can be carried out completely. 

In programming environments, the linking process is used to produce a complete 
program from a collection of program fragments. In addition, linking is used to com- 
bine a number of program fragments without necessarily forming a complete program. 
The result of such an incomplete linking is called a library: in its original meaning, it is 
a library of routines to be used by other programs. Libraries can be linked again to form 
larger libraries or complete programs. A consistent (in ways to be determined) collec- 
tion of linkable program fragments is called a software system, or simply a system. 

Separate compilation, in our framework, maps judgments E h a:A into entities we 
call linksets, over which we can define linking operations. We can see the judgments E 
h a:A as the source module language, and the linksets as the target language of the com- 
pilation. The module language is in this case very rudimentary, but our approach ex- 
tends to other module languages. In Section 4 we consider a more complex module 
language, and in Section 7 we compile it to linksets. 
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2.2 A Simple Configuration Language 

The linking process starts from a collection of program fragments, and from a descrip- 
tion of how the fragments should be combined. This description is traditionally ex- 
pressed in a configuration language, whose complexity can range from simple file- 
naming conventions to sophisticated scripts. These scripts have been named project 
files, makefiles, system models, etc. 

We are going to investigate the simple configuration language of linksets, where a 
collection of fragments to be linked is expressed as a collection of named judgments: 

E 0 I x\ h Ei h 3i ... x n h E n h 3„ 
This is a linkset, consisting of an environment 
E 0 and a collection of judgments E, h 3;, each 
named by a label x,. The components X{ h E, h 
3, are called linkset fragments. 

The main intuitions are that (1) Eo is the external interface of the entire linkset (Eo being 
non-empty for a library, and being empty for a complete program), (2) the environment 
of each judgment is implicitly prefixed by E 0 , so that E 0 , E; h 3, -is a valid judgment, and 
(3) each judgment is labeled by a unique name xf, these names match the free variables 
of other fragments, and thus determine how the fragments hookup 1 . Well-formedness 
conditions for linksets are discussed in detail later. 

A conventional name, such as main, can be reserved for a judgment that denotes a 
complete program. The following is a linkset consisting of a single fragment called 
main. (In our initial examples we take Eo=0.) 

0 I main h (0 h 3+1 : Naf) 

More interestingly, here is a linkset consisting of two fragments: 

0 I 

/h (0 h X(x:Nat)x : Nat^Nat), 
main h (0, f.Nat^-Nat h/(3) : Nat) 

In verbose programming notation, this linkset might be rearranged and written: 

fragment/: Nat^Nat fragment mam : Naf 

import nothing import/: Naf ^Naf 

begin begin 

X(x:Naf)x f&) 

end. end. 



Alternatively one could distinguish between program variables that can be 
freely a-converted and associated labels that connect the fragments, as in [11]. 



6 



In this notation, the fragment/has an empty import list, and produces a value/of type 
Nat-*Nat. The fragment main imports a fragment named / producing a value of type 
Nat^Nat, and produces a value of type Nat. 

As we said, the linking strategy for linksets is specified by choosing names for frag- 
ments that correspond to the free variables of other fragments. Above, it is intended 
that the fragment named/provides a value for the free variable/of the fragment main. 
We can say that "main needs f" (the environment for main contains the assumption 
f.Nat->Nat) while "f needs nothing" (the environment for/is empty). This implicit needs 
relation partially specifies a dependency, or linking order, for the judgments in the 
linkset. 

There are two main activities we can perform on linksets: checking the name and 
type information in a linkset, and performing the actual linking process. We consider 
these in turn. 

The checking activity guarantees that the names and the types are used consistent- 
ly within and across judgments, so that typing can be ignored in the subsequent linking 
phase; this corresponds to intra-module typechecking and to inter-module typechecking. 
In the f, main example above, the intra- fragment typechecking consists in checking, for 
example, that the term X(x:Nat)x has the type exported by the fragment/. The inter-frag- 
ment typechecking consists in checking that the type of the/fragment matches the type 
of the /import of the main fragment. 

The linking activity corresponds, technically, to the repeated application of substi- 
tutions. It assumes that all the typing requirements have been satisfied in the previous 
checking phase. In the example, we can eliminate the / assumption in the main judg- 
ment by substituting /with X(x:Nat)x, and obtaining: 

0 I 

/H0h X(x:Nat)x : Nat^Nat, 
main h 0 h (X(x:Nat)x)(3) : Nat 

Since the typing environments of all the fragments are now empty, no other substitu- 
tions are possible. We have completed the linking process for this example; the relevant 
outcome is the fully linked main program. 

The linking process may fail in some situations, in the sense of not being able to 
empty all environments. For example, the following linkset does not provide a frag- 
ment for y, so the x fragment cannot be fully linked: 

0 I x h 0, y.Nat V- y+1 : Nat 

We will rule out such incomplete linksets. 

A more subtle case of linking failure is due to cyclic dependencies among frag- 
ments. The following linkset is not obviously incomplete, but it still cannot generate a 
runnable program because of a cyclic dependency of its single fragment with itself: 

0 I x h 0, x:Nat h x+1 : Nat 
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Problems with cycles become worse with fragments that are mutually dependent, as in 
the following linkset: 

0 I 

x h 0, y-.Nat h y-1 : Nat, 
y h 0, x:Mrt h x+1 : Naf 

Conceivably, we could eliminate the cycles by converting them into fixpoints. The ear- 
lier linkset could be reduced to: 

0 I x h 0 h \x,{x:Nat)x+l : Nat 

However, we prefer not to go down this road in this paper. The circumstances under 
which cyclic dependencies are acceptable depend strongly on specific languages, and 
are hard to generalize. Moreover, in this paper we will be handling in depth only a sim- 
ply typed X-calculus that is strongly normalizing; hence fixpoints would be out of char- 
acter. We simply let the linking process fail (but not diverge) when presented with 
cycles. In other terms, we rule out recursive and mutually recursive modules. 

3 The Simply Typed X-calculus, Fi 

We now begin formalizing the intuitions of the previous section. We start with a de- 
scription of system Fi, a standard simply typed X-calculus. In the following sections we 
define linksets for Fi. 

The types and terms of F x have the following syntax. The types are either a base 
type K or function types. The terms are either variables, abstractions, or applications. 

Syntax of Fi 

i 1 

A,B ::= K I A^>B types 

a,b ::= x I X(x:A)b I b(a) terms 
i i 

We use a single uninterpreted base type K, but we could easily enrich ¥ 1 with base 
types such as Bool and Nat. 

The environments £ of Fi are lists of typing assumptions of the form 0, X\\A\, 
x n :A n for ri>0; the empty environment is 0. We use the notations dom(E), (E, x:A), (E, £'), 
env(E), and E(x): 

Definition 3-1 (Environment operations) 

• dom(0, Xl :A h x n :A n ) 4 { Xi !eL "}. 

• If E = 0, x\:A\, x n :A n and E' = 0, yr.Bj, y m :B m , 
then £, x n+ r.A n+1 4 0, xi:A lt x„:A n , x n+1 :A n+1 
and £, £' 4 0, x\\A\, x n :A n , y x :B x , y m :B m . 

• env(0, X\\A\, x n :A n ) <=> for all i,jel..n, i*j ^ x&Xj. 

• If E has the shape E', x:A, E" and env(E), then E(x) = A. 
□ 
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The type rules of Fi are given below. They are based on three judgments: £ h o (E 
is well-formed), E h A (type A is well-formed in E), and E\-a:A (term a has type A in £). 

Table 1. Typing rules for Fi 

i 1 

(Env 0) (Env x) 

Eh A xidom{E) 

0 h o £, x:A h ❖ 

(Type Const) (Type Arrow) 
Eh^ E\- A EhB 

£ h X £ h A^B 

(Val x) (Val Fun) (Val Appl) 

Eho E,x:Ahb:B Ehb:A-^B Eh a: A 

E\-x: E(x) E h A,(x:A)fc : A^B E h b(a) : B 

i i 

We list some standard technical lemmas. Here 3 is any judgment right-hand-side 
(including o), and 3{x<— a] is the substitution of a for the free occurrences of x in 3. The 
notions of free and A,-bound occurrences are the standard ones. A technical note: we 
identify terms up to consistent renaming of bound variables, but we do not identify 
judgments up to renaming of environment variables. A judgment-renaming lemma 
can be proved, but will not be necessary here. 

Lemma 3-2 (Fi properties) 

• Implied Judgments. If E, E' h 3 then £ h o. If E, x:A, E' h 3 then E h A. If E h a : A 
then EhA. 

• Weakening. If £, E' h 3 and £, F h o and dom(F) n dom(E') = 0 then £, F, E' h 3. 

• Exchange. If E, F, F', £' h 3 then £, F', F, E' h 3. 

• Substitution. If £, x:A, £' h 3 and £ h a : A then E, E' h Z{x<—a\. 
□ 

From these lemmas we easily obtain the following linking lemma, which states the 
essential conditions under which a linking step can be performed. Here, the program 
fragment a with environment E\, E^ is linked into the "hole" x of 3, adapting the envi- 
ronment Ei, x:A, £3 of 3 to E\, £2, £3. 

Lemma 3-3 (Linking) 

If Ei, x:A, E 3 h 3 and E lr E 2 h a : A 
and dom(0, x:A, E 3 ) n dom(E 2 ) = 0, 
then Ei, £2, E3 h 3{x<— a}. 

Proof 

Assume £1, x:A, £3 h 3 and E\,E 2 \- a: A with dom{0, x:A, £3) n dom(E 2 ) = 0. By Im- 
plied Judgments we have E\, E 2 h o, and by Weakening we obtain Ei, E 2 , x:A, E 3 h 
3. Finally, by Substitution we obtain Ei, £ 2 , E3 h3(i<-ff). 

□ 
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4 Simple Modules for Fi 

As described in the introduction, a judgment £ h a : A can be seen as a simple module. 
In this section we explore a slightly more structured module system for Fi, which cor- 
responds to the following programming notation: 

module module 

import nothing import x:Nat 

export x:Nat export f.Nat->Nat, m:Nat 

begin begin 

x:Nat = 3, f- Nat^Nat = X(y:Nat)y+x 
en( j. m : Nat =f(x) 

end. 

This is one of the simplest conceivable module systems for a programming language. 
A module has a list of imports and a list of exports. The body of a module contains def- 
initions for its exports. Note that there is no mechanism for naming collections of im- 
ports or exports: lists of variables and their types are used explicitly. This module 
mechanism is only a small step forward from the program fragments of section 2.2, but 
at least it supports the grouping of related definitions. A similar mechanism was used 
in early versions of Modula. 

We extend F a with two new judgments for modularization; the way this extension 
is carried out is quite uniform, and can be applied to many type systems [4, 5, 14]. From 
our basic judgments we produce a signature judgment that represents export lists, and 
a binding judgment that represents modules. A signature is essentially a tuple of decla- 
rations, and is similar to an environment. A binding is essentially a tuple of definitions. 

The signature judgment is written E h S (i.e., signature S is well-formed in E); the 
binding judgment is written E h d .-. S (i.e., binding d has signature S in E). 

Table 1. Signatures and Bindings for Fi 



1 

(Signature 0) 


(Signature x) 


i 


Eh* 


E, x:A h S 




Eh-0 


E h x:A, S 




(Binding 0) 


(Binding x) 




Eh* 


E, x:A \-d.-.S 


E h a:A 


E h 0 .: 0 


E h (x:A=a, d) . 


. (x:A, S) 

i 



According to these rules, in E h d .-. S every component of d is matched by a component 
of S in the same position. One could allow signatures and bindings to match more flex- 
ibly, up to reasonable permutations and elisions of components, by instrumenting the 
rules above. Note that signatures and environments associate differently; nonetheless, 
we sometimes identify a signature (xf.A\, (x n :A n , 0)..) with an environment (..(0, 
Xi'Ai), x n :A n ). 
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The two program modules shown at the beginning of this section can be represent- 
ed by the two binding judgments below. The import lists become environments, the ex- 
port lists become signatures, and the module bodies become bindings. 

0 h (x:Nat=3, 0) .-. (x:Nat, 0) 

0, x:Nat h (f.Nat^Nat=X(y:Nat)y+x, m:Nat=f(x), 0) 
.-. (f.Nat^Nat, m:Nat, 0) 

5 Linksets 

As we discussed in the introduction, a linkset is a collection of named judgments plus 
an interface. We now define linksets formally, and we describe a number of conditions 
that identify well behaved linksets. We begin with some terminology. 

Definition 5-1 (Linkset structure) 

Consider the structure L = E 0 I x, • h h 3; ,el "", where each 3; has the shape m : A,. 

Let imp(L) = dom(E 0 ) be the imported names of L. 

Let exp(L) = \x\, x„) be the exported names of L. 

Let names(L) = imp(L) u exp(L) be the names of L. 

Let imports{L) = E 0 be the import environment of L. 

Let exports(L) = 0, Xi:Ai, x„:A n be the export environment of L. 

□ 

We first need to identify linksets that use names coherently, without worrying yet 
about any of the type information. The predicate linkset(L), defined below, captures this 
kind of coherence, which is the minimum required to perform linking. Recall that the 
predicate env(E), from Definition 3-1, asserts that the variables of E are distinct. 

Definition 5-2 (Linksets) 

Consider the structure L = E 0 I x\ h E, h 3, !el "". 
linkset(L) <=> 

• env{imports(L)), and env(exports(L)) 

• for all z'el..n, we have env(E 0 , £,) and dom(Ej) c exp(L) 

• imp(L) n exp(L) = 0. 

□ 

Note that by the condition dom{Ei) c exp{E), L is complete, in the sense that every 
assumption x:A in one of the environments E, is matched by a fragment named x. (Any 
missing fragment must be declared in Eq.) This completeness condition, however, does 
not guarantee the absence of cyclic dependencies. 

We say that a linkset L is linked if all the E; are empty, and is fully linked if, in addi- 
tion, Eq is empty. 

We now define a predicate that refines linkset by performing additional checking. 
This corresponds to the amount of checking performed by separate compilation, before 
inter-module checking. The following definition of the predicate intra-checked guaran- 
tees that each judgment in a linkset is valid in F 1a and that all the judgments have the 
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common prefix Eo. The intra-checked predicate does not guarantee that the fragments 
hook up properly with each other with respect to typing. 

Definition 5-3 (Intra-checked linksets) 

Let L = E 0 I Xi h E f h 3, ,el "". 
intra-checked(L) <=> 

• linkset(L) 

• E 0 h o and, for all i'el..n, we have E 0/ E, h3,. 

□ 

We now turn to checking the consistency of linkset fragments with respect to each 
other. These checks, corresponding to inter-module typechecking, guarantee that the 
fragments forming the linkset can be linked in a type-safe way. 

Definition 5-4 (Inter-checked linksets) 

Let L = E 0 I Xi h E; h 3; ieUn . 
inter-checked(L) <^> 

• intra-checked(E) 

• for all ;,fcel..n, x, A, E', E", 

if Ek has the form £', x:A, E" and x=x ; - then A=Aj. 

□ 

Here we require exact agreement between the fragments (A=Aj). This definition may 
need to be refined in systems more complex than Fi, for example for subtyping. 

Each linkset includes an environment Eo that is meant to describe the fragments 
that are missing from the linkset. Therefore, a useful operation on linksets is to combine 
two of them to mutually reduce the number of missing fragments. This operation pro- 
duces a new linkset that is the merge of the two. We first need some operations on en- 
vironments: 

Definition 5-5 (Environment compatibility and merge) 

• E\X is the environment obtained from E by removing the assumptions x:A such 
that xeX. 

• ElX is environment obtained from E by retaining only the assumptions x:A such 
that xeX. 

• Compatible environments: E\ -H E 2 <=> for all xedom(E{) n dom(E 2 ) we have Ei(x) = 
E 2 (x). 

• We define the merge of two environments E\ and E 2 as E1+E2 = Ei, (E 2 \dom(Ei)). 
□ 

Lemma 5-6 (Commutation of environment merge) 

If Ei -r E 2 and E, {Ei+E 2 ), E' h 3 then E, (E2+E1), E' h 3. 
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Proof 

From Lemma 3-2 (exchange), since E1+E2 is just a permutation of E2+E1 under the 
assumption E\ -H E2. 

□ 

The merge of two linksets is then defined as follows. The imports of the two link- 
sets are merged, except that the fragments mutually exported are removed from the 
combined imports. Then, the exported fragments are merged; the environment of each 
fragment of a linkset is enriched with the imports of that linkset that are exported by 
the other linkset. 

Definition 5-7 (Linkset merge) 

Let L = E 0 I Xi h E; h 3; ,el "", L' = E 0 ' I x{ » E/ h 3;' !el ""'. If linkset(L), linkset(L% and 

exp(L) n exp(L') = 0, then: 

E+E'4 

E 0 \exp(E') + E 0 '\exp(L) I 

X; h Eotexp(E'), E ; h 3; iel "", 

X,-' h Eo'texp(E), E,'h3/' !e1 '"' 

□ 

The following lemmas show that the merge of two linksets preserves the proper- 
ties linkset, intra-checked, and inter-checked, under appropriate assumptions. The proofs 
are given in Appendix. 

Lemma 5-8 (Linkset merge) 

If Hnkset(L), linkset(L'), and exp(L) n exp(L') = 0, 
then linkset(L+L'). 

□ 

Lemma 5-9 (Intra-checked merge) 

If intra-checked(L), intra-checked(L'), 

imports{L) -H imports{L'), and exp(L) n exp(L') = 0, 

then intra-checked(L+L'). 

□ 

Definition 5-10 (Linkset compatibility) 

LtL' <=> 

imports(L) -H imports(L'), imports(L) -H exports(L'), 
imports(L') 4- exports(L), and exp(L) n exp{L') = 0. 

□ 

Lemma 5-11 (Inter-checked merge) 

If inter-checked(L), inter-checked(L'), and L 4- E', 
then inter-checked(L+L'). 

□ 
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6 Linking 

A linkset L contains a set of interdependent fragments of the form x, h £ ; h 3; ,el "". The 
purpose of linking is to resolve the dependencies by making all the £, empty via sub- 
stitutions. 

To perform a single linking step, we find two distinct labeled judgments in L of the 
form: 

x h 0 h «:A 
y h £ h 3 

and we replace the second labeled judgment as follows (without requiring A=A'): 
y h £ \-%{x<-a} 

Formally, a linking step L ~* £' transforms a linkset £ into a linkset £' by perform- 
ing a single substitution: 

Definition 6-1 (Linking steps) 

Let L = (£o I (i H 0h a:A), (y h x:A', £ h 3), ...) and assume linkset{L). 

• L ~* (E 0 I (x h 0 h «:A), (y h E h 3{x<— a}), ...) is a linking step. 

• We write £ W» if there is no £' such that £—*£'. 

• We write for the reflexive and transitive closure of 

□ 

This definition of linking step imposes a rather strict order of reductions by requiring 
one of the environments involved to be empty. One could relax this restriction, and al- 
low more flexible linking orders (such generalizations are supported by Lemma 3-3). 
However, we adopt the simpler definition. 

Linking steps preserve the linkset and inter-checked properties: 

Lemma 6-2 (Properties preserved by linking steps) 

(1) If linkset(L) and L ~* £' then linkset(U). 

(2) If inter-checked(L) and L~*L' then inter-checked{L'). 

Proof 

(1) Easy, from the definition of linkset, since the env property is preserved by shorten- 
ing environments, and names{L) = names(L'). 

(2) Consider L = E 0 I X{ h £, h a{.A\ !el "". Suppose the reduction is carried out on the 
pair (x h 0 h a:A), (y h x:A', E h 3). Since inter-checked(L) by assumption, we have 
A=A', and since intra-checked(L), we have Eo h fl:A and Eo, x:A, E h 3. By Lemma 3- 
3 (linking), we have E 0 , E h3|x<-fl|. Therefore, we have intra-checked(L'), since E 0 , 
E h 3(x<— a) is the only new fragment in L'. Moreover, we have inter-checked(L'), 
since the environments in U are the same as the ones in L except for one that be- 
comes shorter, and the A, are the same (the substitution 3{x<— a] does not affect 
types). 

□ 
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However, intra-checked(L) and L ~* L' do not imply intra-checked(L'). As should be ex- 
pected, intra-checking of fragments is not sufficient for performing linking soundly. 

We state two important properties of linking reductions (sequences of linking steps). 
(1) The inter-checked property is preserved by reductions, meaning that linking does not 
violate typing. (2) Reductions are confluent, meaning that linking steps can be per- 
formed in any order. 

Proposition 6-3 (Subject reduction for linking) 

If inter-checked(L) and L ~*» L', then inter-checked(U). 

Proof 

By Lemma 6-2, the inter-checked property is preserved at every step. 

□ 

Proposition 6-4 (Linking is confluent) 

Assume linkset(L). If L ~** L\ and L ~» L 2 then there exists an L3 such that L\ ~*» L3 
and L 2 ~»» L3. 

Proof 

(1) We first show that if L ~» Li and L ~» L2, then either Li = L 2 or there exists an L3 such 
that Li ~» L 3 and L 2 ~* L 3 . Moreover, linkset(Li), linkset(L 2 ), and linkset(L 3 ). 

By the assumption linkset(L) we know that fragment names in L are distinct. 
Consider two linking steps L ~» L\ and L ~* L2 of the form: 
(E 0 I (xi h 0 h fl i: Ai), (yi h Ei h 3i), ...) 

~* (E 0 I (*i h 0 h flj^j), (y x h Ei h 3i{xi<-fli}), ...) 
(E 0 I (x 2 h 0 h a 2 :A 2 ), (y 2 h x 2 :A 2 ', E 2 h 3 2 ), ...) 

~* (E 0 I (x 2 h 0 h a 2 :A 2 ), (y 2 h E 2 h 3 2 {x 2 ^a 2 }), ...) 
By Lemma 6-2 we have linkset{L\) and Hnkset(L 2 ). Let us consider all possible iden- 
tifications of Xi, yi, X2, and y 2 . 

We have x&yi, x 2 ^\/2, Xi^y 2 , and x 2 ^yi, because of the shape of the associated envi- 
ronments. 

If yi=y 2 we also have Xj=x 2 , by the shape of the associated environments. Then we 
trivially have L\ = L 2 . 

If yi^y 2 (and either xi=x 2 or xvtx 2 ), the two linking steps do not interfere since they 
affect distinct fragments, and we can trivially find an L3 (containing the yi frag- 
ment from L\ and the y 2 fragment from L 2 ) such that L\ ~» L3 and L 2 ~* L3. By Lem- 
ma 6-2 we have HnksetiL^). 

(2) From (1) we can easily show that the reflexive closure ~* R of ~* is confluent: if 
L ~* R Li and L L 2 then there exists an L3 such that L\ ~-» R L3 and L 2 ~-» R L3. (More- 
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over, linkset(Li) for z'e {1,2,3}). The transitive closure of a confluent relation is also 
confluent, by a standard "tiling" argument. Therefore, ~»> is confluent. 

□ 

We can now define a simple linking algorithm that applies linking steps until no 
longer possible. The algorithm attempts to bring the linkset into the linked state, where 
the environments of all the fragments are empty. 

Algorithm 6-5 (Link) 

Assuming linkset(L), the algorithm Link with input L produces an output (L', r) (if 
it terminates) where re {success, failure}. The algorithm iterates from the initial L: 
If L W>, then 

if linked(L) then exit with (L, success), 
else exit with (L, failure). 
Else, choose any linking step L ~» L', 
set L := L', and repeat. 

□ 

We can show that the linking algorithm terminates, and that it is sound and com- 
plete with respect to linking reductions. We also obtain that linking can be performed 
soundly on inter-checked linksets. 

Proposition 6-6 (Link properties) 

• Termination. If linkset(L), then the algorithm Link terminates over the input L. 

• Compatibility. If linkset(L), linkset(L'), L + U, and Link(L) terminates with (L", r), 
then L"tL'. 

• Reduction Soundness. If linkset(L) and Link(L) terminates with (L', r), then L ~*» L'. 

• Reduction Completeness. If linkset(L), L L', and L' w>, then Link(L) = (U, r) 
with re {success, failure). 

• Linking Soundness. If inter-checked(L) then Link(L) = (U, r) for some L' and r, and 
inter-checked(L'). 

Proof 

Termination. The algorithm performs a finite number of iterations, because at every 
iteration either the length of an environment is reduced or the algorithm exits. 

Compatibility. Linking steps preserve the sets imports(L) and exports(L). Therefore 
compatibility is preserved by Link. 

Reduction Soundness. This follows by definition of Link. At each step of the iteration 
the linkset property is preserved by Lemma 6-2. 

Reduction Completeness. Link(L) terminates; assume it produces (L", r). By sound- 
ness, L ~»» L" . By confluence, there exists an Lq such that L' ~»» Lq and L" Lq. 
However, L' W», by assumption, hence we must have L' = Lq. Moreover, L" W», by 
the exit condition of the algorithm, hence we must have L" = Lq. Therefore, L" = U. 
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Linking Soundness. By Termination and Reduction Soundness we obtain L ~»» U. 
Then, by Proposition 6-3 we obtain inter-checked(L'). 

□ 

7 Modules as Linksets 

In this section we consider the module system for Fi of section 4, and we prove safe- 
linking properties for it. A binding, like a linkset, is a collection of fragments. Therefore, 
it is natural to compile bindings to linksets. For example, the binding judgment: 

0, x:Nat h {f.Nat^>Nat=\(y:Nat)y+x, m:Nat=f(x), 0) 
.-. (f.Nat^Nat, m:Nat, 0) 

can be translated to the following linkset, where the environment of the binding judg- 
ment (0, x:Nat) becomes the interface of the linkset: 

0, x:Nat I 

/h 0 h X{y:Nat)y+x : Nat^>Nat, 
m h 0,fNat^Nat h/(x) : Nat 

The general form of the translation of bindings to linksets, is given by the following 
definition. 

Definition 7-1 (Compilation of a binding) 

IE h A :. S} 4 E U0 1- d .-. SF 
iE\-0 ■■■ 0F = empty fragment list 
IE h (x:A=a, d) .-. (x:A, S)F 4 
x h E h a:A, «E, x:A h d .-. SF 

□ 

The following lemma details the correspondence between a binding judgment and 
its corresponding linkset. (Note: we confuse signatures with environments.) 

Lemma 7-2 (Properties of compilation) 

If L = <[E h d .-. S} then importsiL) = E and exports(L) = S. 

Proof 

Clearly, importsiiE h d .-. SJ) = imports(E I {£0 h d .-. SF) = E. 

If L = E I (J, let exports(U) 4 exports(L). We prove that if li = <(E' h d' .-. S'F then ex- 
ports(U) = S', by induction on the translation ^E' h d' .-. S'F- 

Case ^E' I- 0 .-. 0F- We have !J = IE' h 0 .-. 0F - empty fragment list. Hence, exports(U) = 
exports(E I If) = 0 = S'. 
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Case IE' h (x:A=a, d") .-. (x:A, S")T- We have U = x h £' h a:A, IT and IT = x:A h 
d" .-. S"}°. By induction hypothesis we have exports(W) = S". Hence, exports(U) = 
x:A, S". 

□ 

We can now state the first important property of separate compilation: well-typed 
modules are compiled to well-typed linksets. 

Theorem 7-3 (Separate compilation) 

If E h d .-. S then inter-checked(&E h d .-. SJ). 

Proof 

The translation (JE h d .-. SJ) produces a structure of the shape L = £ I Xi h E, h 3; ,el "". 
We have dom(S) = dom(exports(L)) = exp(L), and dom(E) = dom(imports(L)) = imp(L). 

(1) We first show linkset(L) and intra-checked(L) by checking the necessary conditions. 
We have that imports(L) = E, and since Eh d .-. S, we have £h» and env(E). Since 
exports(L) = S and Eh d .-. S, we have env(S). By induction on the derivation of E h 
d .-. S, for all iel..n, we have E, E,- h3i, and env(E, £,-). By construction, each E,- is a 
prefix of S, hence dom(E,) c dom(S) = exp(L). By construction, dom{E) n dom(S) = 0; 
that is, imp{L) n exp(L) = 0. 

(2) To show that inter-checked(L), we note that, by the definition of O", every time an 
assertion is added to an environment, a fragment of the form x H E' h a:A is add- 
ed to the linkset. 

□ 

The second important property of separate compilation is that two well-typed 
modules with compatible interfaces can be safely compiled and merged. For this, we 
first need to define the notion of compatibility of signature and binding judgments: 

Definition 7-4 (Signature and binding compatibility) 

(E h S) t (£' h S') 4 

£ -r £', E -r S', E' -r S, and dom(S) n dom(S') = 0. 
(£ h S) t (E' h d' .-. S') 4 (EhS)H-(E'hS') 
(Ehd.-. S) -=-(£' hS') 4 (EhS)H-(E'hS') 
(E h d .-. S) -7- (E' h d' .-. S') 4 (E h S) -r (£' h S') 



Lemma 7-5 (Compatibility under compilation) 

Assume (E h d .-. S) H- (£' h d' .-. S'). 
Then, «E h d .-. SD h- <JE' h d' .-. S'J>. 

Proof 

By definition 7-4, (E h d .-. S) 4- (£' h d' .-. S') implies (£ h S) -f (£' h S'), and hence E H- 
E', E -r S', E' -r S, and dom(S) n dom(S') = 0. Take L = «E h d .-. SJ> and L' = «£' h d' .-. 
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S'5>. By Lemma 7-2, imports(L) 4 imports(L'), imports(L) 4 exports(L'), exports(L) 4 im- 
ports(L'), and exp(L) n exp(L') = 0. Therefore, by Definition 5-10, L 4 L'. 

□ 

We now show that compatibility of signatures is a sufficient condition for the safe 
merge of separately compiled modules: 

Theorem 7-6 (Separate compilation and merge) 

Assume E h d .-. S, E' h A' .-. S', and (E h S) 4 (£' h S'). 
Then, inter-checkeA{&E h d .-. SJ}+«E' I" d' .-. S'D). 

Proof 

Let L = ^E h A .-. S} and L' = ^E' h d' .-. S']>. By Theorem 7-3 we have inter-checkeA(L) 
and inter-checkeA(L'). Since (E h S) 4- (E' h S'), we also have (E h d .-. S) 4- (E' h d' .-. S') 
by Definition 7-4. By Lemma 7-5 we obtain L 4- L'. Therefore, by Lemma 5-11 we 
have inter-checkeA(L+L'). 

□ 

Note that the linking of ^E h A .-. S}+iE' \- A' .-. S'5> may still produce failure, because cyclic 
dependencies may be present between E h d .-. S and E' h d' .-. S'. 

8 Summary 

We can summarize our main definitions and results by recasting them as an inference 
system for establishing the soundness of sequences of compilation and linking steps. 

In the following inference rules, M is a module represented by a binding judgment 
E h A .-. S, and L is a linkset; iM} is the compilation of a module to a linkset. By valiA(M) 
we mean that M is derivable (type-consistent). M^M'is type-compatibility between 
modules (or their interfaces). By inter-checkeA{L) we mean that L is type-consistent. L 4- 
U is type-compatibility and L + L' is merging of linksets. By Hnk(L) = U we mean that 
the linking algorithm Link(L) yields (U, r) where r is success or failure. The relations in- 
dicated by 4- are symmetric. 

Table 1. Separate compilation inference system 

i 1 

(Compilation) (Theorem 7-3) 

valiA(M) 
inter-checkeA{lM}j) 

(Compilation compatibility) (Lemma 7-5) 
valiA(M) valiA(M') M4M' 

&MD 4 «M'J> 
(Linking) (Proposition 6-6) 
inter-checkeA(L) 

inter-checkeA(link(L)) 
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(Linking compatibility) (Proposition 6-6) 
inter-checked(L) inter-checked(L') L + L' 

link(L) -r L' 
(Merge) (Lemma 5-11) 

inter-checked(L) inter-checked(L') L + L' 

inter-checked(L+L ') 

i i 

From these rules, we can show that a separately compiled valid module M can be 
safely partially linked. That is, that inter-checked{link{{Mff) holds: 

valid(M) assumption 

=> inter-checked{lMf) by (Compilation) 

=> inter-checked{link{iM})) by (Linking) (1) 

Furthermore, the following derivation shows that two separately compiled compatible 
valid modules M and M', one of which has been partially linked, can be safely linked 
together. That is, that inter<hecked{link{link{{Mf)+iM'})) holds: 

valid(M') assumption 

=> inter-checked{lM'f) by (Compilation) (2) 

valid{M), valid(M'), M H- M' assumptions 

=> «MJ) -r ((AO by (Compilation compatibility) (3) 

linkilMf) -r {M'l by (1), (2), (3), (Linking compatibility) (4) 

inter-checked{link{{MJi)+iM'f) by (1), (2), (4), (Merge) 

=> inter<hecked{link{link{iMf)+iM'f)) by (Linking) 

Thus, inference systems such as the one outlined here can be used to check the va- 
lidity of complex sequences of compilation and linking steps, at a reasonable level of 
abstraction. 



9 Conclusions 

The linking process, once obscure and undocumented, is becoming increasingly visible 
and sophisticated. In some instances, it is becoming part of language semantics. 

We suggest that linking and separate compilation should be seriously taken into 
account when designing a language and module system. This sentence may seem a tru- 
ism, but these issues have been surprisingly under-emphasized in the technical litera- 
ture. We have shown that linking can be given a technical content. We have formalized 
linking via linksets, and we have formalized separate compilation as the ability to 
translate modules separately to linksets that can be safely linked. The general intuition 
is to regard linking as the repeated application of type-preserving substitutions. 
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We have studied a simplistic module system. It should be possible to use the same 
basic ideas to explore other module mechanisms, hopefully more realistic ones. Many 
directions of further work are possible, including the following: 

• Alternative linking reductions and algorithms. 

• Linking algorithms that handle mutual dependencies. 

• A more realistic linking process that does not cause code expansion or loss of module 
identity (by using explicit substitutions [2]). 

• Convenient naming of module interfaces, and support for the dot notation [6]. 

• Flexible signature matching and subtyping. 

• Linking and separate compilation for the polymorphic X-calculus, F 2 , with the aim of 
covering the modularization features of Modula-2. 

• Design of advanced module systems that are nonetheless able to support separate 
compilation [3, 13]. 

• Study of dynamic linking. 
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Appendix 
Lemma 5-8 

If linkset(L), linkset(L'), and exp(L) n exp(L') = 0, then linkset(L+L'). 
Proof 

Let L = E 0 I Xi h E f h 3, ,el "" and L' = E 0 ' I x,' h h 3;' ieUn '. We verify the conditions 
require by linkset(L+U), from Definition 5-2. 

(1) From env(E 0 ) and env(E 0 ') we have env(E 0 \exp(L') + E 0 '\exp(L)), by definition of +. 
That is, env{imports(L+L')). 

(2) Since the x,- are distinct, and the x{ are distinct, and because of the assumption 
exp(L) n exp(L') = 0, we have that all the x„ x,' are distinct. That is, env(ex- 
ports(L+L')). 

(3) Since dom(Ej') cz exp{L') and dom(Ej) c exp(L), we have that dom(Eo\ exp(L'), E,) = 
dom(E 0 \ exp(L')) u dom(E,) c exp(L') u exp(L) = exp{L+L'). Similarly, dom(E 0 '\exp(L), 
E,') c exp(L+L'). 

(4) We have imp(L+L') = dom(Eo\exp(L') + Eg'\exp(L)) = (imp(L)-exp(L')) u 
{imp(L')-exp(L)), and exp(L+L') = exp(L) u exp(L'). By assumption, we have 
imp(L) n exp{L) = 0 and imp(L') n exp(L') = 0. Now, (imp(L)-exp(L')) n exp(L) = 0 and 
(imp(L)-exp(L')) n exp(L') = 0, therefore (imp(L)-exp(L')) n (exp(L) u exp(L')) = 0. 
Similarly, (fmp (L')-exp(L)) n (exp(L) u exp(L')) = 0. Hence ((imp(L)-exp (L')) u 
(imp(L')-exp(L))) n (exp(L) u exp(L')) = 0. That is, imp(L+L') n exp(L+L') = 0. 
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(5) We need to show that: 

env(E 0 \exp(L') + E 0 '\exp(L), E 0 \exp(L'), E,) 
env(E 0 \exp(L') + E 0 '\exp(L), E Q '\exp(L), £,-') 

From the assumptions env(E 0 , E,) and env(E 0 ', E,') we trivially have env(E 0 \exp(L'), 
E,) and env(Eo'\exp(L), E,'). Moreover, case (1) shows env(Eo\exp(L') + Eo'\exp(L)). 
So, we are left to show that dom(Eo\exp(L') + Eo'\exp(L)) = imp(L+L') is disjoint from 
both dom(E 0 \exp(L'), E,) and dom(E 0 '\exp(L), £,'). Now, case (3) shows that the latter 
two are included in exp(L+L'), and case (4) shows that imp(L+L') n exp(L+L') = 0. 
Therefore, we are done. 

□ 

Lemma 5-9 

If intra-checked(L), intra-checked(L'), 

imports(L) -H imports(L'), and exp(L) n exp(L') = 0, 

then intra-checked(L+L'). 

Proof 

Let L = E 0 I x; h E; h 3, i£l " n and L' = E 0 ' I x,' h E,-' h 3,' iel ""'. 

(1) By Lemma 5-8, we have linkset(L+L'). 

(2) We need to show that: 

Eo\exp(L') + Eo'\exp{L), Eo\exp(L'), E; h 3; 
By Lemma 3-2 (implied judgments) we have Eo l~ o and Eq h o, from which: 

E 0 \exp(L'), (Eo'\exp(L))\dom(E 0 \exp(L')) I- o 
As in Lemma 5-8(5), since dom((E 0 '\exp(L))\dom(E 0 \exp( L')) c dom(E 0 \exp(L') + 
E Q '\exp{L)): 

dom((E 0 ' \ exp(L)) \ dom(E 0 \ exp(L ')) n 

dom(E 0 \ exp(L'), E,) = 0 
By Lemma 3-2 (exchange), from Eo, E; 1-3;: 

E 0 \exp(L'), E 0 \exp(L'), E, h 3; 
By Lemma 3-2 (weakening), from the previous three results: 

E Q \exp{L'), (E 0 '\exp(L))\dom(E 0 \exp(L')), E 0 \exp(L% E, h 3, 
This is the same as: 

E 0 \exp(L') + E 0 '\exp(L), E 0 \exp(L'), E, h 3, 

(3) We need to show also that: 

E 0 \exp(L') + E 0 '\exp(L), E 0 '\exp(L), E{ h 3,' 
Or equivalently, by Lemma 5-6, since imports(L) -H imports(L'), that: 

E 0 '\exp(L) + E 0 \exp(L'), E 0 '\exp(L), E{ h 3,' 
By Lemma 3-2 (implied judgments) we have Eq\- o and Eo' l~ o, from which: 
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Eo'\exp(L), (Eo\exp(L'))\dom{Eo'\exp{L)) h o 
As in Lemma 5-8(5), since dom((E 0 \exp(L'))\dom(E 0 '\exp( £)) c: dom(E 0 \exp(L') + 
E 0 '\exp{L)): 

dom((E 0 \ exp(L ')) \ dom(E 0 '\ exp(L)) n 

dom(E 0 'lexp(L), E,') = 0 
By Lemma 3-2 (exchange), from Eq', E{ h3;': 

E 0 '\exp(L), Eo'l'exp(L), E;' h3,' 
By Lemma 3-2 (weakening), from the previous three results: 

Eo'\exp(L), (E 0 \exp(L'))\dom(E 0 '\exp(E)), E 0 '\exp(E), h 3,' 

i.e. E 0 '\exp(L) + E 0 \exp(L'), E 0 '\exp(L), E{ h 3,' 
By Lemma 5-6, since imports{L) -H imports(L') we conclude: 

E 0 \exp(E') + E 0 '\exp(L), E 0 'fexp(L), E,' h 3,' 

□ 

Lemma 5-11 

Assume inter-checked(L), inter-checked(L') r 
imports(L) -H imports(L'), imports(L) -H exports(L'), 
imports(L') -H exports(L), and exp(L) n exp(L') = 0. 
Then inter-checked(L+L'). 

Proof 

Let E = Eo I X,- h E,- h 3, ' e1 "" and L' = E 0 ' I x/ h E,-' h 3,' iel ""'. 

(1) By Lemma 5-9, we have intra-checked(L+L'). 

(2) We have the following fragments for L+L': 

X; H Eotexp(L'), E; h 3; !el "", 
x;' H Eq'\ exp(L), E{ h 3;' 

By assumption, we know that: 

1) If E; has the form F, x:A, G then there exists a; (since dom(El) c exp(L)) with x=x ; - 
and A=A ; -. 

2) If £,-' has the form F', x':A', G' then there exists a; (since dom(E,') c: exp(L')) with 
x'^xy' and A '=A{. 

We need to show that for any assumption z:C appearing in Eol'exp(E'), E, or 
Eo'l'exp(L), E,', if there is a fragment named z in L+L', it has type C. 
For any assumption in E,-, and £,' the hypotheses apply. 

For an assumption x:A in E 0 lexp(L'), we have that E 0 =imports(L) 4- exports(E'). 
Hence x:A is in exports(L'), which means that there is an xf=x with Af=A. 
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For an assumption x':A' in Eo'\exp{L), we have that Eo' = imports(U) 4- exports(L). 
Hence x':A' is in exports(L), which means that there is an xpx' with Aj=A ' . 

□ 
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